Skip to content

docs: (PRO-300) Add JSON-RPC API docs generator and update scripts#220

Merged
amilz merged 1 commit intomainfrom
docs/typedoc-generate-per-method-JSON-RPC-API-documentation
Sep 5, 2025
Merged

docs: (PRO-300) Add JSON-RPC API docs generator and update scripts#220
amilz merged 1 commit intomainfrom
docs/typedoc-generate-per-method-JSON-RPC-API-documentation

Conversation

@amilz
Copy link
Copy Markdown
Contributor

@amilz amilz commented Sep 5, 2025

Introduces a script to generate JSON-RPC API fumadocs documentation from the TypeScript SDK typedocs, and updates .gitignore to exclude generated API reference files (they will be migrated to the launch fumadocs page).

Example Use

pnpm run docs:all

> @kora/sdk@0.1.0 docs:all /kora/sdks/ts
> pnpm run docs && pnpm run docs:api


> @kora/sdk@0.1.0 docs /kora/sdks/ts
> typedoc --readme none && node scripts/add-toc.js

[info] Loaded plugin typedoc-plugin-markdown
[info] markdown generated at ./docs
✅ Added methods table of contents to documentation

> @kora/sdk@0.1.0 docs:api /kora/sdks/ts
> node scripts/generate-api-docs.js

📖 Reading TypeDoc output...
📋 Found 10 methods and 24 response types
✓ Generated estimate-transaction-fee.mdx
✓ Generated get-blockhash.mdx
✓ Generated get-config.mdx
✓ Generated get-payer-signer.mdx
✓ Generated get-payment-instruction.mdx
✓ Generated get-supported-tokens.mdx
✓ Generated sign-and-send-transaction.mdx
✓ Generated sign-transaction.mdx
✓ Generated sign-transaction-if-paid.mdx
✓ Generated transfer-transaction.mdx
✓ Generated overview.mdx

✅ API documentation generated successfully!
📁 Output: /kora/docs/api-reference-generated

Example Output


title: estimateTransactionFee
description: Estimates the transaction fee in both lamports and the specified token.

JSON-RPC Request

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "estimateTransactionFee",
  "params": {
    "transaction": "base64EncodedTransaction",
    "fee_token": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v"
  }
}

JSON-RPC Response

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "fee_in_lamports": 5000,
    "fee_in_token": 1000000,
    "payment_address": "3Z1Ef7YaxK8oUMoi6exf7wYZjZKWJJsrzJXSt1c3qrDE",
    "signer_pubkey": "3Z1Ef7YaxK8oUMoi6exf7wYZjZKWJJsrzJXSt1c3qrDE"
  }
}

cURL Example

curl -X POST http://localhost:8080 \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"estimateTransactionFee","params":{"transaction":"base64EncodedTransaction","fee_token":"EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v"}}'

TypeScript SDK

const fees = await client.estimateTransactionFee({
  transaction: 'base64EncodedTransaction',
  fee_token: 'EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v' // USDC
});
console.log('Fee in lamports:', fees.fee_in_lamports);
console.log('Fee in USDC:', fees.fee_in_token);

Important

Adds a script to generate JSON-RPC API documentation from TypeScript SDK typedocs and updates scripts in package.json.

  • Scripts:
    • Adds docs:api and docs:all scripts in package.json to generate JSON-RPC API docs.
    • New script generate-api-docs.js to parse TypeDoc output and generate JSON-RPC API documentation.
  • Documentation Generation:
    • Parses TypeDoc README to extract method information and response types in generate-api-docs.js.
    • Generates JSON-RPC request/response examples and TypeScript SDK usage for each method.
    • Creates documentation files for each method and an overview file in docs/api-reference-generated.
  • Misc:
    • Updates .gitignore to exclude generated API reference files.

This description was created by Ellipsis for 23c4a48. You can customize this summary. It will automatically update as commits are pushed.

Introduces a script to generate JSON-RPC API documentation from the TypeScript SDK, adds new npm scripts for API docs generation, and updates .gitignore to exclude generated API reference files.
@amilz amilz requested a review from dev-jodee September 5, 2025 21:45
@amilz amilz self-assigned this Sep 5, 2025
@linear
Copy link
Copy Markdown

linear bot commented Sep 5, 2025

@github-actions
Copy link
Copy Markdown

github-actions bot commented Sep 5, 2025

📊 TypeScript Coverage Report

Coverage: 82.0%

View detailed report

Coverage artifacts have been uploaded to this workflow run.
View Artifacts

Copy link
Copy Markdown
Contributor

@ellipsis-dev ellipsis-dev bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Important

Looks good to me! 👍

Reviewed everything up to 23c4a48 in 2 minutes and 55 seconds. Click for details.
  • Reviewed 430 lines of code in 2 files
  • Skipped 1 files when reviewing.
  • Skipped posting 6 draft comments. View those below.
  • Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. sdks/ts/package.json:30
  • Draft comment:
    New docs scripts were added (docs:api and docs:all). Ensure the generated API docs folder is properly ignored (e.g. via .gitignore) if it’s not meant to be committed.
  • Reason this comment was not posted:
    Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% This is a speculative comment - it says "if it's not meant to be committed". We don't know if these docs are meant to be committed or not. The comment is asking the author to verify something rather than pointing out a definite issue. We also don't have visibility into the .gitignore file or the generate-api-docs.js script to know what the intended behavior is. The comment raises a valid point about generated files potentially needing to be gitignored. Not having proper gitignore settings could lead to unwanted files being committed. While the concern is valid, the comment is speculative and asking for verification rather than pointing out a definite issue. We don't have enough context to know if this is actually a problem. Delete this comment because it's speculative and asks for verification rather than pointing out a definite issue that needs fixing.
2. sdks/ts/scripts/generate-api-docs.js:40
  • Draft comment:
    The regex for extracting the properties table is brittle and assumes a fixed markdown format. Consider documenting the expected structure or making the parser more resilient.
  • Reason this comment was not posted:
    Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 30% vs. threshold = 50% The comment raises a valid concern about code maintainability. The regex is indeed quite specific and could break if the TypeDoc output format changes. However, this is a documentation generation script, not core application logic. The format of TypeDoc output is fairly standardized and unlikely to change frequently. The comment doesn't suggest a clear alternative approach. The comment identifies a real technical debt issue, but may not be actionable enough. What specific improvements would make the parser more resilient? Just documenting the expected structure doesn't solve the brittleness. While the regex is brittle, this is acceptable for a documentation tool where the input format is controlled and stable. The complexity of making it more robust may not be worth the effort. The comment should be removed. While technically correct about the brittleness, it doesn't provide actionable suggestions and the current approach is reasonable for a documentation generation script.
3. sdks/ts/scripts/generate-api-docs.js:119
  • Draft comment:
    The regex used to extract the return type (e.g. /Promise\<\[(\w+)\]/) is tightly coupled to a specific TypeDoc format and may break if that format changes. Consider a more robust approach.
  • Reason this comment was not posted:
    Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% The comment raises a valid concern about maintainability - the regex is indeed brittle and assumes a very specific markdown format. However, this is a documentation generation script, not core application logic. Some degree of coupling to the documentation tool's output format is inevitable. The current approach, while not perfect, is simple and gets the job done. A more robust approach would likely add significant complexity for minimal benefit. The comment correctly identifies a potential maintenance issue. If TypeDoc changes its output format, this script would break. However, this is an internal documentation generation script where some coupling to TypeDoc's format is expected. The suggested "more robust approach" is vague and would likely overcomplicate things. While technically correct, the comment suggests adding complexity to solve a hypothetical future problem in a documentation tool. The current simple approach is adequate for this use case.
4. sdks/ts/scripts/generate-api-docs.js:188
  • Draft comment:
    Defaulting to an empty array for 'params' when no parameters exist might be inconsistent with common JSON-RPC usage (which typically uses an empty object {}).
  • Reason this comment was not posted:
    Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% While both [] and {} are technically valid in JSON-RPC 2.0, {} is more commonly used in practice. However, this is a style preference rather than a correctness issue. The code will work fine either way. The comment is suggesting a change that isn't strictly necessary. The comment raises a valid point about common JSON-RPC usage patterns, but it's more of a style preference than a functional issue. Since both formats are valid according to the JSON-RPC 2.0 spec, and the current code works correctly, this change isn't critical enough to warrant a comment. The comment should be removed since it suggests a style change rather than fixing a real issue, and both formats are valid according to the spec.
5. sdks/ts/scripts/generate-api-docs.js:310
  • Draft comment:
    The list of RPC methods is hardcoded. This approach requires manual updates when new methods are added. Consider dynamically deriving the list from parsed methods for improved maintainability.
  • Reason this comment was not posted:
    Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% While it's true that the list is hardcoded, there are good reasons for this: 1. The RPC methods need to be carefully curated - not all SDK methods should be exposed as RPC endpoints 2. The code already handles missing methods gracefully with a warning at line 333 3. The hardcoded list serves as documentation of what methods are intentionally exposed 4. Making it dynamic could expose internal methods unintentionally The comment identifies a real maintainability concern - when new RPC methods are added, developers need to remember to update this list. However, having an explicit list of exposed RPC methods is a security feature and helps with API stability. The minor maintenance burden is worth the control and clarity it provides. The hardcoded list is intentional and beneficial, despite the small maintenance cost. The comment should be deleted.
6. sdks/ts/scripts/generate-api-docs.js:407
  • Draft comment:
    The file lacks a newline at the end. Adding a trailing newline can help avoid potential issues with some tools and linters.
  • Reason this comment was not posted:
    Confidence changes required: 50% <= threshold 50% None

Workflow ID: wflow_hy0Wg0ce9HvcIduL

You can customize Ellipsis by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.

@amilz amilz merged commit ece4b9b into main Sep 5, 2025
3 checks passed
@amilz amilz deleted the docs/typedoc-generate-per-method-JSON-RPC-API-documentation branch September 5, 2025 23:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants